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PDP~X design goals 

^his memo outlines the goals of the PDP-X project* While the 
ohjectives axe reasonahly firm, the techniques to "be used in 
implementation are still very much under study. 

1. Modern processor design 

a. Current -DSC small computer desifms are 'limited 

"by their architecture to mal^e very inefficient use of the 
available technology. For example j both the PBP-SI and the PDP-9 
have all the necessary hardware to implement an index register 
hut their Op Code-'structure prohihits this. PDP~X architecture 
should ma>.e far better use. of the available technology, yielding 
an improved price performance ratio, %ice PT)?-9 performariCe at 
half its price is a reasonable goal. 

"b* Over the past few years the relative costs of 

memory and digital logic has shifted. FDP-X architecture should 
restore the balance thus minimising total system costs. ?ho 
principal method will be to reduce progTam core storage requirements 
without unduly increasing central processor complexity. The Op 
Code set should, 'for example , feature more powerful instructions 
and a more flexible addressing structux-e. 

0* PD?~X basic configurations must expand neatly 

over a f ar- v/ider range than CDxrent products. Use of read only- 
storage (PCS; for Op Code expansion avr^I speciaJ iDerhiDheral 
controllers should permit increasing system capability at moderate 
cost. The addition of integrated, active memoi':^^ arraj'-s Y,dll 
speed interrupt processing as well as the more complex instructions. 
If the design sells \7ell5 one can reasonable exi^ect to eventually 
offer 3 processors, all of v/hich use the same architecture* These 
would replace the present ^DV-^B^ Pi)P~9, and PDP--24. 

N 



c 



^» ^ii© architectixre "should- be implemented aroiond 

hardY;are readily available at the "begining of processor life but 
should also. be amenable to the use of internal scratch pad memories j 
gate arraysj and otheJfornis of large scale integration (L3I). 
®* ^^^' current experience in the hardv/are necessary 

for complex scft^rare systems (eg? bacltgrour.d'/foreground monitor) 
must be imbedded into the basic design rather than tacked on as 
an afterthought. The hardware necessary for dj^amic memory 
allocation/protection J privileged instruction traps ^ etc.j should 
be easily, but optionall;^, implemented. 

2, Fourth generation design 

8-« The basic processor j if it is to be the basic 

building block of the next several years products y m.ust easily 

:■ expand into the next generation designs,. i%ltiprocessing 

capability in its most general (and effective) form still lies 
beyond the reach of current techniques t however j it should be 
possible to implement the larger perhipheral devices (egs -^gtape) 
using the basic processor asid suitable ROS, Such "m.ini-multiprocessor" 
design should also help break the • proajaction bottleneck on 
perhipherals that we face today. 

"b. -^n ultimjate goal is the facility for horizontal 

system, expansion! the ability to increase r-ystem performance 'bj 
a-dding additional 5 identical processors^ The attainm.ent of this 
goal lies fa.r ahead, 

3» Standardized 10 

a. To mdnimdze. the cost of the simpler perhipheral 

devices J identical harc;;,'are must be used frith,, all .'versions of ;, the 
processor. A standard byte interface is the m^ost likely choice 
to accomplish this. 
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"b. • - While the software goals still lack much detail 5 
the follOY/ing three stages have heen culled from I^arrj/" Portner's 
group and anticipated comt)etition5 
stage 1 ~ "basic asseinbler 

editor 

"basic utilitj'- routines * 

'stage 2 -. macro assei:i"bler 

compiler 

10 system 
sta.ge 3 — keyboard monitor 

extended monitor (as required.) 

Stage 1 sof t-\Yare should "be oriented aroux^d a 
minimum configuration, stages 2,3 around a PD?-9 class s^fstea 
with requisite options* 

c. The software should, be modular so that it can 

be eventually run in a monitor environment and require a.s little 
as pos^^iible to -be simultaneously core resident. It should also 
bo re-entrant whenever possible to fs,cilita,te use during interrupts 
and in a multi-user environment «■ 



6, Anticipated schedule 

a. hardware 
system architecture 
prints for basic system 
prototype constructed 
protot;>l>e ruoining 

b, soft^.vare 
simulator 

stage 1 basic 

basic diagnostic 

final ■orocessor diagnostic 



Sept 1 '67 

Feb 1 ' 63' 

Apr 1 ♦68 

July 1 '68 

Dec 1 '67 

^%r 1 ^68 

Feb 1 »68 

Sept 1 *68 
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documentation 



architect"ure 
specification,^' 
user handbook 



Sept 1 '67 
Sept 1 ' 68 
Jan 1 ^69 



* documenta,t ion will be concurrent vritli development. Specifications 
refers to detailed 10 timing, etc., sufficientlj^ firm that they may 
"be used in contracts. 



